Serial No. 10/675,903 Docket No. 14449US02 

Amendment Under 37 C.F.R. § 1.116 
February 14, 2006 

REMARKS 

The present application includes pending claims 1-31, all of which remain 
rejected. By this Amendment, claims 2, 12, and 22 have been amended as set 
forth above. The Applicants respectfully submit that the claims define patentable 
subject matter. 

Claims 2, 12, and 22 were rejected under 35 U.S.C. 112, second 
paragraph, as being indefinite. These claims have been amended as set forth 
above to overcome this rejection. 

Claims 1-5, 8-15, 18-25, and 28-31 remain rejected under 35 U.S.C. 
102(e) as being anticipated by United States Patent Application Publication 
2003/0158928 ("Knox"). Claims 6-7, 16-17, and 26-27 remain rejected under 35 
U.S.C. 103(a) as being unpatentable over Knox in view of United States Patent 
No. 2004/0064575 ("Rasheed"). The Applicants respectfully traverse these 
rejections at least for the reasons set forth previously during prosecution and the 
following: 

I. Knox Does Not Anticipate Claims 1-5, 8-15, 18-25, And 28-31 

The Applicants first turn to the rejection of claims 1-5, 8-15, 18-25, and 28- 

31 as being anticipated by Knox. The Office Action responds to the Applicants' 

previous Amendment by stating the following: 

Knox does disclose about the user interfaces (see 
figs. 4-9), e.g., "display", which provides functions for 
remote user's selecting as disclosed in page 6, para 
[0048], including for the selecting bandwidth as 
disclosed in page 5, para [0041], bit rate as disclosed 
in page 6, para [0043], cost and quality of service as 
disclosed in page 6, para [0046]; page 7, paras [0050- 
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0051]' and where the server receives the request from 
end user for distributing the files as disclosed in page 
4, para [0033]; pages 5-6, paras [0043, 0046-0047, 
0049]; page 7; paras [0050-0051]. Therefore, 
Examiner concludes that Knox teaches the arguable 
features. 

See December 22, 2005 Office Action at page 8. The Applicants respectfully 
disagree. 

As shown above, in an attempt to counter the Applicants' previous 
remarks regarding claims 1, 11, and 21, the Office Action relies on Figures 4-9, 
and Paragraphs [0033], [0041], [0043], and [0046]-[0051] of Knox. Initially, the 
Office Action seemingly relies on Figures 4-9, merely to show a "display." 
However, the Applicants respectfully submit that these Figures do not teach or 
suggest "causing a display of a plurality of quality of service options 
corresponding to at least one media file for selection by a remote user" and 
"receiving a quality of service selection specifying at least one of said plurality of 
quality of service options," as recited in claims of the present application 

Paragraph [0033] of Knox states the following: 

To this end, FIG. 1 depicts a number of different web 
sites 17. A web site, for the purpose of this 
description, will be understood as a directory or 
several directories of content, including optionally 
executable content, that is associated with a network 
address and that is to be delivered over the Internet 
either as data content or a service. In FIG. 1, the four 
different web sites are shown as having a set of files 
in this case, each web site having three files. 
However, this is just an arbitrary number of files 
shown for the purpose of illustrating the structure and 
operation of the distributed file system 26. For the 
purpose of this description, each of the three depicted 
files for each web site is representative of a streaming 
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media asset. A streaming media asset typically would 
be an Mpeg file, AVI file, or some other type of audio, 
visual or audiovisual file that has been translated into 
a streaming format such as Real Media, Windows 
Media or QuickTime. The software transcoders 
needed for performing this type of translation are 
available and any suitable software for performing this 
translation may be employed to generate the files 
depicted in the web site 17 of FIG. 1. The upload, 
storage, editing and check-in processes of the 
distributed file system 26 enable a client 12 to upload 
a data file from one of the client's 12 and into the 
respective web site associated with that client 12. 
Additionally, the distributed file system includes 
processes that allow the client to manipulate 
characteristics of that data file, wherein the 
characteristics that are being manipulated are 
relevant to a streaming media assets. The 
manipulation of this data will be described in greater 
detail below. Additionally, to make the delivery of the 
streaming media assets more efficient, the system 26 
copies, or replicates, the streaming media asset and 
distributes the replicated streaming media assets 
across a support system capable of providing multiple 
hosts for delivering the streaming media asset to a 
requesting user. In the embodiment depicted in FIG. 
1, the support systems for the distribution of 
replicated data files can include a set of 
geographically distributed servers, depicted by 
element 19 of FIG. 1, or from partner networks, such 
as the Akamai network depicted by element 21 of 
FIG. 1. 



This portion of Knox merely discloses general concepts of uploading a file, 
manipulating characteristics of a file, and delivering a streaming media asset. 
The Applicants respectfully submit, however, that there is nothing in this 
paragraph that teaches or suggests "causing a display of a plurality of quality of 
service options corresponding to at least one media file for selection by a remote 
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user" and "receiving a quality of service selection specifying at least one of said 

plurality of quality of service options." 

Moving on, Paragraph [0041] of Knox reads as follows: 

In operation, the distributed file system 26 allows a 
user to select a content file 28 to upload to the staging 
area 14 that will be provided by the distributed file 
system 26. Typically the client 12 does an FTP upload 
to the distributed file system 26. Upon detecting the 
request to FTP a file 28, the web server 13 servicing 
the customer 12 determines the location of the 
customer 12 and finds the DFS node 14A or 14B that 
is closest to, has sufficient capacity, or otherwise is 
best suited or adequately suited to serve the needs of 
the customer 12. Upon determining the proper DFS 
node, the web interface creates an account on the 
node. The account acts as a staging area 14 from 
which the file 25 may be replicated, distributed, and 
checked into the distributed file system 26. For 
example, once the web interface has identified the 
proper node 14A or 14B and created an account for 
the customer 12, a window is presented to the 
customer 12, through which the customer 12 can 
select the file 28 to be uploaded. Once the file 28 is 
uploaded to the staging area 14, meta data is 
identified from processing the file. The meta data can 
include the name of the file, its length, its file type, the 
bandwidth for which it was created, start and stop 
points, and any other suitable meta data that may be 
selected from the file. The file 28 and its meta data is 
then replicated and for each replicated file a unique 
signature id is created and associated with that 
physical file. In one embodiment, the unique id is a 
128-bit number that is created using a hashing 
technique that, in one practice hashes the user 
identification, file name and other information. 
However, those of ordinary skill in the art will 
understand that any suitable technique may be 
employed for creating a unique id for a physical file, 
and any suitable technique may be employed. 
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This portion of Knox discloses that a user can select a file, which may include 

various components, to upload through a window. Much like Paragraph [0033], 

however, this portion of Knox does not teach or suggest "causing a display of a 

plurality of quality of service options corresponding to at least one media file for 

selection by a remote user" and "receiving a quality of service selection 

specifying at least one of said plurality of quality of service options." 

Next, Paragraph [0043] of Knox discloses the following: 

Once the accounts are created the process 40 
proceeds to step 48 wherein the user is allowed to 
select a file to be uploaded. In one practice, the 
process 40 allows the user to access the distributed 
files system 26 through a web interface. In this 
practice, the process 40 can employ the web 
connection between the customer and the web server 
of the host to provide graphical user interfaces to the 
customer. For example, the process 40 may employ 
the web connection to create user interfaces that 
allow the user to upload files to the staging area 14, 
check the files in, and browse the files that are 
currently stored in the web site. Such user interfaces 
are depicted in FIGS. 4 and 5. For example, FIG. 4 
depicts a user interface that presents the customer 
with a number of optional services such FTP upload 
to staging area, check in files, browse files, file 
search, file recovery, and user account administration 
features. Each depicted user interface may be a 
standard HTML page that employs HTML forms and 
controls to collect input from the customer. FIG. 5 
depicts a graphical user interface, also an HTML 
page, that facilitates file transfer between the client 
system and the host. To this end the HTML page 
allows the user to drag a file icon onto the screen of 
the graphical user interface. The graphical user 
interface collects the file and automatically begins to 
upload the file from the client to the host system. After 
step 48, the process 40 proceeds to step 50 wherein 
the data file uploaded to the host system is processed 
to determine, or identify meta data associated with 
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that file. In this step, the process 40 can execute a 
computer process that is capable of analyzing the 
contents of the uploaded data file. For example, the 
file structure of the uploaded data file may be known 
to the process and may be identified to that process 
by the file extension associate with the uploaded file. 
For example, a *.rm file indicates a file format 
compatible with the Real Media file structure. The 
process 40 can include logic that understands the file 
structure of the *.rm format. The file structure typically 
includes information regarding the title of the file, the 
size of the file, an associated codec, bit rate and other 
characteristics of that file. 

This portion of Knox discloses that a user may gain access to a distributed file 

system through a web interface, which may include a graphical user interface. 

One user interface may include optional services. Similar to Paragraphs [0033] 

and [0041], however, this portion of Knox does not teach or suggest "causing a 

display of a plurality of quality of service options corresponding to at least one 

media file for selection by a remote user" and "receiving a quality of service 

selection specifying at least one of said plurality of quality of service options." 

Paragraph [0046] states the following: 

When determining the number of replicated files to 
make, as well as where these replicated files are to 
be located, the systems described herein may employ 
a profile that is set up for each file uploaded by the 
customer. The profile may have predetermined 
characteristics wherein the selected predetermined 
characteristics for each file turns on the price, or 
selected quality of service the customer has chosen 
for that file, or for their service in general. Thus a 
customer wanting maximum service from the systems 
described herein may have a profile that indicates a 
high number of replicated files is to be created and 
these files are to be distributed across the network 
including onto servers that are part of third-party 



15 



Serial No. 10/675,903 Docket No. 14449US02 

Amendment Under 37 C.F.R. § 1.116 
February 14, 2006 

customer distribution networks (CDN), such as the 
Akamai network. 

In general, this portion of Knox discloses profiles used for various file types that 

are configured before each individual file is chosen. While files are distributed 

based on the pre-configured profile, this portion of Knox, much line Paragraphs 

[0033], [0041], and [0043] does not teach or suggest "causing a display of a 

plurality of quality of service options corresponding to at least one media file for 

selection by a remote user" and "receiving a quality of service selection 

specifying at least one of said plurality of quality of service option," as recited in 

the claims of the present application. 

Turning now to Paragraph [0047] of Knox, as discussed above, the profile 

is a general set of characteristics that apply to files uploaded subsequent to 

configuration of the profile. 

Based on the profile, user information, and perhaps 
historical data of earlier similar requests and 
achieved performance, the server may select the 
best node to serve the client from, and will generate 
a redirection link directing the client to make a 
request to the location best suited to server that 
customer. Thus, the client should receive service 
according to the profile selected by the customer 
website. 

Id. at Paragraph [0047]. Again, Knox discloses profiles that are configured 
before selection of files. That is, a user configures a preferred profile before 
selecting particular files. The pre-configured profile is then applied to 
subsequently-selected files. Knox does not, however, teach or suggest "causing 
a display of a plurality of quality of service options corresponding to at least one 
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media file for selection by a remote user" and "receiving a quality of service 

selection specifying at least one of said plurality of quality of service options," as 

recited in the claims of the present application. 

Paragraph [0048] of Knox states the following: 

Turning to FIGS. 7-9, it can be seen that the above 
described distributed file system also provides 
additional functionality to a user for helping the user 
manage their web site. For example, FIG. 7 depicts a 
user interface presented by the system 26 to the 
client 12 through the browser, that allows the user to 
browse the different files, and the meta-data 
associated with those files, that are stored on the 
user's web site 17. Once the user is satisfied that the 
meta-data and other characteristics of the stored files 
are correct, the user can initiate the check-in 
operation described above with reference to FIG. 3. A 
similar interface is presented in FIG. 8, however in 
this interface the user is provided with a play control 
70 that allows the user to play the streaming media 
file through the appropriate player. This allows the 
user to verify that the file is correct and operating 
properly, without requiring the user to log into the web 
site separately or download the file to the client 12 for 
examination. FIG. 9 depicts a further interface that 
allows the user to identify which of the content 
distribution networks the user would like to select for 
deploying and distributing the streaming media asset. 
As can be seen in this embodiment, the user can 
select through the checkbox controls 80, one or more 
of a plurality of available content distribution networks, 
similar to how meta-data characteristics are selected. 
The process 40 of FIG. 3 can process the user 
selections and register the user's content with the 
selected content networks for the delivery thereby. 

While this portion of Knox discloses that a user may identify "which of the content 

distribution networks... to select for deploying and distributing the streaming 
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media asset," much like Paragraphs [0033], [0041], [0043], [0046], and [0047], 

this portion of Knox does not teach the relevant claim limitations noted above. 

Next, Paragraph [0049] of Knox states the following: 

Turning to FIG. 10, it may be understood that a quality 
of service application may also be provided. Thus the 
file system 26 described herein can provide tools for 
monitoring the "Quality of Service" (QOS) for 
streamed content. Streamed content is more sensitive 
to quality of service issues than static content. 
Accordingly, customers will be far more interested in 
the quality of service provided across the Internet, or 
other network, when streamed content is being 
delivered. 

This portion of Knox merely discloses that Quality of Service may be monitored, 
which is not the same as "causing a display of a plurality of quality of sen/ice 
options corresponding to at least one media file for selection by a remote user" 
and "receiving a quality of service selection specifying at least one of said 
plurality of quality of service options," as recited in the claims of the present 
application. Similar to Paragraphs [0033], [0041], [0043], [0046], [0047], and 
[0048], this portion of Knox does not teach the relevant claim limitations noted 
above. 

Paragraph [0050] of Knox states the following: 

To address this issue, the file system 26 may 
optionally include a quality of service ("QOS") tool or 
process that provides bi-directional access to mission 
critical data related to the intelligent management of 
streaming media content. In particular, a customer 
may employ the QOS process to access mission 
critical data, such as the quality of service being 
provided to the customer's clientele, when the 
clientele are located at different locations on the 
network. To this end, the QOS process communicates 
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with a plurality of monitors across the network. A 
typical monitor may comprise a Linux Workstation 
running an agent that simulates the actions of several 
common media players, such as the Windows Media 
player and QuickTime Player. The monitor will gather 
stream-specific data from many different locations 
throughout the network and transfer the information 
back to a central depository where it is parsed, 
processed, and made available for client access and 
review. The client employing a web interface may 
access an account provided by the QOS process 
where the client can view and understand the quality 
of service that is being achieved for their streams 
traveling across different paths over the network. 
Additionally, the distributed file system can use the 
quality of service information to determine what 
content will be or has been provided over what paths 
on the Internet, as well as for selecting paths, 
networks, or characteristics of paths, for the delivery 
of content. In this way, the host can offer clients the 
right to purchase hosting services that have different 
prices for different subscribed or delivered quality of 
service. 

As shown above, Knox states that "the host can offer clients the right to purchase 

hosting services that have different prices for different subscribed or delivered 

quality of service." See id. at Paragraph [0050]. While Knox notes that the host 

can offer clients the right to purchase hosting services, Knox does not teach 

or suggest "causing a display of a plurality of quality of service options 

corresponding to at least one media file for selection by a remote user" and 

"receiving a quality of service selection specifying at least one of said plurality of 

quality of service options," as recited in the claims of the present application. 

Finally, Paragraph [0051] of Knox states the following: 

For example, FIG. 10 depicts that a plurality of agents 
may be distributed across the data network at certain 
locations. These agents may imitate the operation of 
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a Windows Media Player, a Real Media Player, or 
some other type of player. The agents can determine 
the type of response that they are receiving at that 
location of the network, and may return a collected 
information to a central repository that may optionally 
be maintained at the servers 30. Additionally, and 
optionally, the quality of service application may also 
collect the logs from the servers that have been 
streaming data to the clients. These logs contain 
information about the success that was achieved 
when delivering data to an end user station such as 
the depicted end user stations 40. Accordingly, the 
QOS application creates a data base of information 
about the quality of service that has been provided to 
a customer. In one optional practice, the billing 
process for a customer turns, in part, on the quality of 
service that has been provided to that customer 
during the delivery of streamed content. In this way, 
the platform described herein may deliver content to a 
user at a selected cost to that user. 

As noted above, the Quality of Service application is merely a tool for monitoring 

the quality of service. In particular, as shown above in Paragraph [0051], the 

"QOS application creates a data base of information about the quality of service 

that has been provided to a customer." Similar to Paragraphs [0033], [0041], 

[0043[, and [0046] - [0050], however, this portion of Knox does not teach or 

suggest "causing a display of a plurality of quality of service options 

corresponding to at least one media file for selection by a remote user" and 

"receiving a quality of service selection specifying at least one of said plurality of 

quality of service options," as recited in the claims of the present application. 

As shown above, none of the portions relied upon by the Office Action 

(i.e., Figures 4-9, Paragraphs [0033], [0041], [0043], and [0046]- [0051]) teach or 

suggest the relevant claim limitations. Thus, at least for this reason, the 
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Applicants respectfully submit that the Office Action has not established a prima 

facie case of anticipation with respect to claims 1-5, 8-15, 18-25, and 28-31. 

II. Knox Does Not Teach Or Suggest "Transfer Via At Least One Of A 
Media Guide, Channel Guide, And A Device Guide" 

In response to the Applicants' remarks regarding claims 5, 15, and 25, the 

Office Action states the following: 

Knox does disclose about the server, which receives 
the request from the end user as disclosed in figs. 7- 
9; and distributes the file as request (sic) as disclosed 
in page 5, para [0036]; page 6, para [0047]0048]. 
Therefore, Examiner concludes that Knox teaches the 
arguable features. 

See December 22, 2005 Office Action at page 8. Thus, the Office Action relies 

on Paragraphs [0036], and [0047] - [0048] of Knox to reject these claims. 

Paragraph [0036], however, states the following: 

For the depicted system, the customer content 12 is 
streamed content that is derived from a media source 
22 and that is encoded by encoder 24 into a format, 
such as, for example, the Windows Media format or 
the Apple Quick Time format. The encoded data files 
are stored as the media-on-demand files 28 depicted 
in FIG. 2. 

This portion of Knox merely discloses that content may be derived from a media 
source. It does not, however, teach or suggest "transfer via at least one of a 
media guide, channel guide and a device guide." A media source is not 
necessarily a media guide. Similarly, Paragraphs [0047]-[0048] (reproduced 
above) do not teach or suggest a media guide, channel guide and a device 
guide. "Checkbox controls," as recited in Paragraph [0048] are not necessarily a 
"media guide, channel guide, [or] a device guide." 
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The Applicants respectfully submit that Knox does not teach or suggest 
"transfer via at least one of a media guide, channel guide and a device guide." 
As noted above, the Office Action cites Figures 7-9 and Paragraph [0048] to 
support rejection of claims 5, 15, and 25. Figures 4-9 of Knox illustrate "user 
interface screens provided by the system of FIG. 1 for allowing a user to manage 
content on a website." See Knox at Paragraph [0024]. Figure 7 of Knox 
illustrates a "Destination Directory:/airplane", which shows filename, size, date, 
title/author/copyright, and file type. Figure 8 shows a similar directory, while 
Figure 9 seemingly shows specifics of the file. These Figures, however, do not 
teach or suggest "transfer via at least one of a media guide, channel guide and a 
device guide." Thus, at least for these reasons, the Applicants respectfully 
submit that the Office Action has not established a prima facie case of 
anticipation with respect to claims 5, 15, and 25. 

III. The Proposed Combination Of Knox And Rasheed Does Not Render 
Claims 6-7, 16-17, And 26-27 Unpatentable 

The Applicants next turn to the rejection of claims 6-7, 16-17, and 26-27 
as being unpatentable over Knox in view of Rasheed. The Applicants respectfully 
submit that the combination of Knox and Rasheed does not render these claims 
unpatentable at least for the reasons discussed above. 

IV. Conclusion 

The Applicants respectfully submit that the claims of the present 
application should be in condition for allowance at least for the reasons 
discussed above and request reconsideration of the claim rejections. If the 
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Examiner has any questions or the Applicants can be of any assistance, the 
Examiner is invited to contact the Applicants. The Commissioner is authorized to 
charge any necessary fees or credit any overpayment to the Deposit Account of 
McAndrews, Held & Malloy, Account No. 13-0017. 



McAndrews, Held & Malloy, Ltd. 
500 West Madison Street, 34th Floor 
Chicago, Illinois 60661 
Telephone: (312)775-8000 
Facsimile: (312)775-8100 



Date: February 14. 2006 
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